4.2 Implementing a Service Desk infrastructure
Designing your Service Desk support
infrastructure correctly is critical to success and should be done as a formal
business improvement project with clear ownership, defined business goals, responsibilities,
deliverables and management commitment.
However, before even starting to identify your needs, consider the basic premise
of what you want to achieve. This is an opportunity to re-evaluate the whole
way you have, to date, delivered service. Don't just think of automating current
manual processes, using staff in the same way. Consider a rethink and redesign
of the processes and activities in order to increase productivity, add value,
reduce cost and improve the Customer's
perception. Consider the question 'If this was your business, would you organise
it, resource it, and run it, this way?'
4.2.1 Staff resourcing
An operational service needs to be maintained on a daily basis. It is not therefore always practical to
expect 'business as usual' and still implement a successful service-improvement project. Additional
resource is generally required to assist during the project set-up phase.
A major consideration is the skill sets available within your organisation to deliver this project
successfully. It is essential that the project team involved has proven Service Management and
implementation skills.
Where 'business as usual' cannot be maintained due to implementation of a service-improvement
project, it is important, as well as acquiring additional resource, to communicate
this fact to the Customer.
In situations where skilled resource is a problem, the usage of contract and outsourced services should
be considered. Utilising and training by internal resources should also be investigated, for example by
transferring staff from other teams in the department or releasing staff from non-critical projects.
4.2.2 Target effectiveness metrics
Decide and set targets for a manageable number of objective metrics for the
effectiveness of the Service Desk.
This task requires careful consideration, because the post-implementation and
subsequent ongoing reviews will compare these targets with reality. Take the
metrics into account during the technology-tool selection and design stages.
Guidelines for setting metrics include the following:
- do not set targets that cannot be measured
- maintain the metrics in the light of detailed design activities, ensuring their necessity and viability
- establish a baseline before discussing formal Service-Level Agreements
(SLAs) with
Customers
- general SLAs may be offered to provide a framework to start collecting metrics
and using them to measure performance against the SLA criteria
- ensure that Customers are aware of what you are doing, and why.
In relation to SLA criteria, and subject to request volumes, baseline data should be collected for a
period of approximately two months to ensure a viable sample is available for analysis. It is critical to
understand the levels of service you are currently providing with the current resources available before
making changes.
4.2.3 Key considerations
Here are some key points for consideration when setting up a Service Desk:
- first establish that the business need is clearly identified and understood
- make sure management commitment, budget and resource is made available before
commencement
- ensure the proposed solution aligns with your Service Support strategy and vision
- identify, achieve and communicate quick wins (e.g. keeping customers informed, improved
installation times)
- define clear objectives and deliverables
- start simple; don't try to do everything at once; adopt a phased approach
- involve/consult your Customers, especially critically important ones; don't
use jargon
- involve/consult end Users
- sell the benefits to support staff
- train IT staff to be service staff
- educate/train Customers
and Users in the
use of the new service and its benefits
- advertise and 'sell' your service.
4.2.4 Selecting the right Service Desk structure
The type of Service Desk, skill
level and organisational structure you choose is dependent on a number of important
factors. There is no 'universal' configuration to suit all. As your business
changes, so will your support operation; therefore flexibility is crucial to
support future growth.
4.2.5 Types of Service Desk structure
Three types of structures should be considered for optimum usage:
- local Service Desk
- central Service Desk
- virtual Service Desk.
These are each described in more detail below.
4.2.6 Local Service Desk considerations
Traditionally, organisations have created local support desks (see Figure 4.7) to meet local business
needs. This is practical until multiple locations requiring support services are involved. Duplicating skills
and resources will become very expensive. If your organisation is maintaining several local support desks,
it is important that operational standards are introduced.
Figure 4.7 - Local Service Desk
Considerations for implementing a local Service Desk structure include:
- establishing common processes across all locations and, where possible, common procedures
- making localised skills known and available to other Service Desks
- ensuring compatibility of hardware, software and network infrastructure
- using the same escalation processes, and the same impact, severity, priority and status codes across all
locations
- normalising top-level request classifications to allow for common reporting on major service
components (see paragraph 4.2.11)
- using common management reporting metrics
- using a (logically) common shared database
- if available, putting in place the ability to pass or escalate requests
between Service Desks, preferably automatically.
4.2.7 Central Service Desk considerations
In this arrangement, all service requests are logged to a central physical location, as shown inFigure
4.8. If your organisation has multiple locations, having a central support service has major business
benefits, including:
- reduced operational costs
- consolidated management overview
- improved usage of available resources.
Figure 4.8 - Centralised Service Desk
4.2.8 Virtual Service Desk considerations
To a great extent the physical location of the Service
Desk and the associated services are immaterial. This is largely due to
advances in network performance and telecommunications. The 'Virtual Service
Desk' (Figure 4.9) can be situated and accessed from anywhere in the world.
If your organisation has multiple locations, having a single global support service has major business
benefits, including:
- reduced operational costs
- the scope for a consolidated management overview
- improved usage of available resources.
However, the prime operational restriction to the Virtual Desk is the need for a physical presence by a
specialist or replacement engineer.
Figure 4.9 - Virtual Service Desk
Considerations when setting up a Virtual Service Desk include the following:
- All persons accessing the Virtual Service Desk should use common processes,
procedures and terminology.
- A common, agreed-on language should be used for data entry.
- Customers and Users
still need to interact with a single point of contact. Consider global telephone
numbers, local numbers that route to the Virtual Desk and Automatic Call Distribution
(ACD) technology.
- There will be the need for a physical presence on site by a specialist or maintenance engineer from time
to time.
- Network performance should be 'fit for purpose'. This should be reviewed
in terms of forecast workloads. For example, if the local Service Desk in
Holland is only handling ten requests a day, then network volume may not be
a major consideration. However, a narrow bandwidth is not practical if several
hundred requests are processed.
- For the Virtual Desk, the support tools in place should allow for 'workload partitioning' and authorised
views. (For example, if I am the person looking after local support in, say, Amsterdam, I only want to see
requests for that location.) This should include other associated processes and related data, such as planned
Changes, asset and configuration data.
- Consistent ownership and management processes for Incidents
should be used throughout the Virtual Service Desk, with automated transfers
of Incidents and Incident views between local desks.
4.2.9 Service Desk Configuration considerations
The criteria to decide on the best configuration for your organisation are varied, but should
include:
- business objectives and deliverables
- maturity and skill levels of the existing support organisation
- budget, costing and charge-back mechanisms
- levels and quality of the management information required
- size of organisation and nature of business
- political considerations
- organisational structure:
- whether single location, multiple locations or a global location
- number of Customers
to be supported
- working hours to be covered
- language(s) spoken by both support staff and Customers
- range, number and type of applications to be supported:
- standard
- specialised
- bespoke
- general business requirements (e.g. office tools)
- network infrastructure (local, wide-area)
- range, number and types of hardware/technology to be supported
- technology replacement cycle
- skill levels of Customers
- skill level of User base
- skill levels of support staff
- number of support staff (first and second-line)
- reliance on third-party organisations
- current call volumes.
4.2.10 Global 'follow the sun' support
When an organisation is providing 24-hour support, or extended cover, around the globe, the following
points should be considered:
- the ability of telecommunications systems/switches to interact
- is time-zone support included in Service
Level Agreements?
- is management reporting available in local and remote time zones?
- is local language support available?
- the need for multilingual support staff
- local considerations and cultural needs (e.g. in Spain, working days are often split between morning
and early evening)
- localised SLAs and Operational-Level Agreements (OLAs) may need to be defined
- clear escalation channels and management-reporting chain
- all local desks should use consistent ownership and management processes
for Incidents, with automated transfer of Incidents and Incident views between
local desks.
Design Consideration
Furthermore, if you wish to pass requests between Service
Desks or merge them in the future, consider agreeing unique identification,
prefixing and number ranges for your global network, so as to avoid the problems
that might arise if you have requests with the same number.
4.2.11 Incident classification
Classification
is one of the most important attributes of an Incident
to get right. Classification is used to:
- specify the service or equipment to which the Incident relates
- associate any Service
Level Agreement or Operational Level Agreement in place
- select/define the best specialist or group to handle the Incident
- define the priority and business impact
- define a workload estimate
- define what questions should be asked or information checked
- act as a matching criterion for selecting solutions, Known Errors or Work-arounds
- summarise and define the final action taken (e.g. training required, no fault found)
- define a primary reporting matrix for management information.
The final classification(s) may vary from that initially reported. The Customer
may have reported a 'symptom' of an Incident
and not necessarily the root Problem.
The levels of classification will vary depending on the detail required. For
example, a top-level classification of 'Word Processing', or 'Payroll Service'
is adequate for an overview; however, greater detail may then need to be obtained
in areas such as:
- version number
- supplier
- software module (e.g. printing, bought ledger)
- grouping (e.g. business application).
When an Incident is completed, it is beneficial, for certain types of request,
to enter a 'closure classification' or 'closure code'. This should state the
actual cause, a summary conclusion, or a specific course of action. Examples
include:
- Incident completed successfully
- Customer training required
- documentation needs reviewed
- no fault found
- monitoring required
- advice given
- Change request needs to be raised.
Detailed classification will ensure more effective management information.
The management information provided by reporting against classification should
be reviewed regularly to ensure that meaningful, up-to-date, data is returned.
However, one should not overcomplicate this process by adding too many classifications
initially, because this may cause confusion when support staff are registering
Incidents.
It is also recommended that standard classifications such as 'Unknown' or 'Unable
to classify' be included, as this will prevent support staff from making a 'best
guess'. These Incidents can later be reviewed and classifications generated/amended,
if required. In general, it is best to start simple and expand as business needs
demand it.
Start simple and expand as the business needs demand it.